Table of Contents
Previous Section
Table of Contents
Previous Section
In WebScript, the scope of variables depends on where and how you declare them. The notion of scope in WebScript really encapsulates two different ideas: a variable's visibility and its lifetime.
The simplest kind of variable in WebScript is a local variable, which is declared inside a method as follows:
- aMethod {
id localVar;
/*...*/
}
Local variables have no visibility outside of the method in which they're declared, and no lifetime beyond the method's execution. For this reason, they're the only type of variable that can't be referenced in a declarations file.
Variables that have some degree of persistence within your application are called scoped variables. To understand the role of scoped variables, it's useful to think about the flow of activity in a WebObjects application. The life of a WebObjects application is marked by the continual recurrence of two events: requests (such as a user clicking on a control to initiate an action), and the subsequent responses (such as the server returning a dynamically generated HTML page in response to a request). Processing and variable scoping in a WebObjects application are organized around these two events.
Scoped variables behave differently depending on whether they're declared in an application script (where they're called session and global variables) or in a component script (where they're called transaction and persistent variables).
The scoped (that is, non-local) variables you declare in an application script are one of two types: global variables or session variables.
Global variables are visible to all users of an application, and they last for the duration of an application. A global variable is available in every page and across all sessions. There is one copy of the variable per application. Global variables are declared in the application script outside a method as follows:
id globalVar;
Whereas all users of an application see a global variable with the same value, each session has its own version of session variables. A variable with session scope lasts for the duration of a session. A session represents a browser (user) accessing a WebObjects application, which could be serving multiple users. A session is initiated when a browser (single user) connects to a WebObjects application, at which time the session is assigned a unique identifier. This session ID is stored in the pages associated with the application. The session ID lasts as long as the user's browser stores the pages associated with the application, even if the browser is used to navigate to pages not associated with the application.
A session variable is visible in every component script. Its value is archived and restored at the beginning and the end of each transaction. There is one copy of the variable per client (user session). Session variables are declared in the application script outside a method as follows:
session id sessionVar;
Both global and session variables are persistent---that is, global variables last for the duration of the application, and session variables last for the duration of the associated user session.
Note that in a component script, you always access global and session variables through the WOApplication object, since it owns them:
id value = [WOApp mySessionVariable]; [WOApp setMyGlobalVariable:newValue];
The scoped (that is, non-local) variables you declare in a component script are one of two types: transaction variables or persistent variables.
A transaction variable is declared outside a method, as follows:
id myVar;
A variable with transaction scope lasts for the duration of the transaction, or client request. A transaction is defined as a client request coming in and a response (usually an HTML page) going out. By the time the response is returned to the client, the variable no longer exists. Transaction variables are visible to all of the methods within the script in which they're declared.
A persistent variable is declared outside a method using the persistent keyword, as follows:
persistent id myVar;
A persistent variable remains valid for a particular page for the duration of a session. It is archived when a response is generated for a user request and restored when the client performs an action on the new page.
Whenever possible, you should refrain from using persistent variables in a component script since they tend to degrade performance. It's preferable to restore the variable for which you might otherwise maintain a persistent variable. For example, if you have a list of hyperlinks on a page, you should recreate them in the script's awake method instead of maintaining them in a persistent variable, for example:
id myLinks; // just use a regular transaction variable...
// ... then re-initialize it in the script's awake method
- awake {
myLinks = @("My Autobiography", "Pictures of my Dog");
return self;
}
There are two cases in which you should use persistent variables in a component script:
It's important to remember that pages aren't persistent in an application. They are created at the beginning of a transaction, and they disappear at the end. The life of a page actually spans two transactions:
Between these two occurrences, the WOWebScriptComponentController associated with a page is destroyed and reconstructed. Any variables in your component script that aren't declared as persistent are lost. Consequently, variables whose values the page depends on need to either be made persistent or recreated in awake. The preferred approach is to recreate them in awake, as described in the preceding section.
Next Section